Subject: SSP Header Shortcoming

From: "Steve Klein (254-5623)" <[email-masked]>
Date: Thu, 24 Mar 94 10:03:24 EST

Reference: Note from Frank Bordonaro dated Mon, 14 Mar 94 18:19:44 PST

Frank, is there a reason why the existing Header Length field is not
adequate?  I don't really see a need for a length field in the
Information Message Header and as long as all new header formats
include the existing Header Length field at the same offset as the
Control Message header, we should have no problem creating new formats.

Steve

>I would like to point out a shortcoming of the current SSP header
>and propose a solution. I realize that it is late in the game, but
>I think a little pain now may be worth saving bigger pain later.
>
>The main problem is that the SSP Message Type field is overloaded.
>It explicitly calls out the message type and implies the message
>length based on the type. The problem arises when new message types
>are defined and a new message type is sent to a dlsw peer that
>does not recognize the new message type. The peer receiving the new
>message will not recognize it and must guess at it's SSP header length.
>If it guesses incorrectly, it will never get back in synchronization
>to read the next SSP header.
>
>Since the standard is still evolving and most likely will continue
>to evolve for some time, it seems very likely that new message types
>will be defined. There are several ways to avoid the loss of SSP header
>alignment and subsequent tearing down of the TCP session.
>
>The first is that for all SSP message types not recognized, the receiver
>could assume a certain size (probably 72 bytes). Although this is a
>viable option, it limits the kinds of SSP header improvements we could
>make, namely reducing the size of the header for control messages.
>
>The second option is to add a new SSP header field to both control and
>information headers called Message Header Length. This would allow
>unrecognized SSP messages to be discarded and the next SSP header to
>be read without difficulty.
>
>I would propose that we chose adding the Message Header Length field
>because it allows for creative and optimal use of SSP headers as we
>learn. If we are defining a standard that will live for any period of
>time, this gives us some flexibility.
>
>Frank Bordonaro
>[email-masked]
>cisco Systems, Inc.

---

From: Frank Bordonaro <[email-masked]>
Date: Wed, 30 Mar 94 19:41:54 PST

Steve,
 
  As I re-read my original note, I see I did not express my thought
  as clearly as I would have liked. Let me try again.
 
  As long as the "new" SSP formats are at least 20 bytes in length
  and include the existing Header Length field at the same offset as 
  the Control Message header, we will have no trouble creating new
  formats. My point is that the above restiction is totally unnecesary.
  For the flexibility to be creative and reduce the SSP header in size 
  to something less than 20 bytes, *all* SSP messages should start with 
  the Header Length followed by the Message (data) Length and then followed
  by the Message Type. This does not tie our hands in any way for future 
  SSP message formats. If an SSP receiver does not recognize the Message
  type, it knows the header and message (data) length and can find the 
  start of the next frame in the TCP pipe.
 
  From my experience, backwards compatibility is the biggest problem
  as a product evolves. The better job we can do up front to make
  it easier for the product to grow/change, the better off we will be.
 
  My intent is to bring this to your attention. If it makes sense to  
  other vendors as it does to us, then we should consider a change. If
  not, we will all have to handle backward compatibility in our own way.  
 
Regards,
Frank Bordonaro